Method and system for updating derived items in a view model which includes multiple coordinate systems

ABSTRACT

A computer graphics interface between an application program and device pipeline. The computer system implements a view model including a plurality of coordinate systems. An acyclic graph is stored, wherein the acyclic graph representing dependencies between various items in each of the plurality of coordinate systems. Upon a creation of an item in a first coordinate system of the plurality of coordinate systems, an object is associated with the item an object which associates all derived items from the item in others of the plurality of coordinate systems, wherein the object includes a first flag for indicating whether the item current item is valid within the first coordinate system. The object further includes a second flag for indicating that at least one of the derived items is not valid in its respective coordinate system. Upon requests for the item by the application program, it is determined whether the item is valid, and if not, then the acyclic graph is descended to determine when one of the derived items is valid. When one valid item is found, the item is calculated and it is indicated that the one item is valid. Then, the acyclic graph is ascended, calculating each derived item, and indicating that each derived item is valid until reaching the requested item. Then, the requested item is calculated, a flag is set indicating that it is valid and the requested item is presented to the application program. The storage of the object further allows entry of data from multiple coordinate systems, and provides a fast test to indicate that derived items are invalid.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to computer graphics systems. Morespecifically, this invention is a facility for perforating the geometricprocessing of a view model, which is configured by an applicationprogram in a computer graphics system.

2. Background Information

In computer graphics systems, a view model defines operations to beperformed on geometry to be rendered. The view model has a number ofcoordinate systems where application programs specify operations. Forexample, in some prior art systems, a three-dimensional view modeltypically defines four coordinate systems: Model Coordinates (MC),Global Model Coordinates (GMC), World Coordinates (WC), Virtual DeviceCoordinates (VDC), and Device Coordinates (DC). Each coordinate systemis a convenient place to specify operations. For example, theapplication specifies geometry in MC, lights in WC, view clip planes inVDC, and a pick aperture in DC. A sequence of matrices transformgeometry from coordinate system to coordinate system where operationssuch as lighting, view clipping, and picking are performed. The MC-to-WCmapping is called the model matrix and the WC-to-VDC mapping is calledthe view matrix. The model matrix, view matrix, lights, and view clipplanes are all context attributes of the view model. Applicationsspecify these to configure the view model.

The view model is conceptual in the sense that an implementation on agraphics device actually may perform an operation in a coordinate systemother than the one where the application specifics it as long as theresult is the same. Device pipelines do this for improved performance.

Prior art high performance graphics devices typically retain view modelstates such as matrices, lights, and clip planes. But they are morerestrictive than the conceptual view model. For example, they typicallyrequire the MC-to-CC and CC-to-DC matrices (CC is Clipping Coordinates,which is not exposed at the application program interface [API] level),and lights in MC and LC (LC is Lighting Coordinates, which is notexposed at the API level). These items are derived from the API viewmodel attributes. When an application changes an attribute, an itemderived from that attribute becomes invalid. It must be recalculated,and the device must be informed of the change so that the devicepipeline can reload the derived item into the device. In some prior artsystems, when an application program sets a view model attribute in thecontext, all invalidated items are recalculated at the time of change tothe attribute. This results in unnecessary calculations at every stagein the pipeline and consumes unnecessary system overhead because anapplication may change several view model attributes before sending agraphics primitive. Each attribute change results in a completerecalculation.

A graphics primitive is a function that takes geometry in MC, passes itthrough the geometry pipeline for transformation and clipping, andrenders it in DC. An example of a primitive is polyline, which is anordered set of vertices with each pair connected by a line segment. Thepolyline primitive takes at least two vertices in MC, transforms thevertices to CC, clips the polyline so that no geometry extends outsideor the viewing rectangle, transforms the clipped vertices to DC, andrenders the line segments between each pair of vertices.

Another example of a primitive is annotation text, which is a characterstring where each character is rendered with polylines. Font files holda description of the polyline representation of each character. Theannotation text primitive takes a character string and a reference pointin MC and transforms the reference point to VDC. If the reference pointis inside the viewing rectangle, it builds a polyline representation ofthe character string in VDC. It would be extremely convenient if apipeline could send these polylines to the polyline primitive above sothat the annotation primitive does not have to duplicate the remainderof the geometric pipeline and the entire rendering pipeline.Unfortunately, the text is in VDC now, and the polyline primitiveexpects geometry in MC. This poses a problem. Therefore, it would bedesirable if a device interface would support entry of items from avariety of coordinate systems, as the device pipeline requires.

One prior art method of changing context and its effect on the graphicspipeline will now be discussed. This method will be known as "dumbevaluation" because the system does not account for subsequent changesto the specified or subsequent contexts prior to performingcalculations. Using this prior art technique, first, an application mayset view model attributes in context. Upon a detection of this change,the system will then store the values in memory and calculate nothing.Subsequent to this operation, the application may then call a graphicsprimitive, such as that requiring the rendering of an object. Thegeometry can then be passed to the device pipeline (DP), and the DPcalculates "derived" items (those changing in subsequent view models dueto the changes in the specified context) from view model attributesspecified in the given context. The DP loads derived items into a device(sometimes a hardware graphics accelerator), and the DP sends thegeometry to the device. The disadvantage of this technique is that ifthe view model attributes do not change between graphics primitives (avery common occurrence) then derived items are calculated and loadedunnecessarily into the device. These calculations reduce overall systemperformance.

A second prior art technique is known as "automatic evaluation." Usingthis technique, an application program can set a view model's attributesin a specified context, and those changes are stored into memory. Then,the derived items, may be recalculated from the view model attributesand they are stored into memory referenced by the context. Subsequent tothese operations, the application program may call a graphics primitive.At this point, geometry is passed to the DP and the DP getsprecalculated derived items (from the changes in context performedabove) from the context and loads them into the device. Then, the DPsends the geometry to the device. The disadvantages of this techniqueare that if the application sets several view model attributes betweengraphics primitives (a not uncommon occurrence) then all derived itemsfrom the changes in contexts will be re-evaluated after each change tothe view model. All calculations occurring before the last change to theview model thus are unnecessary. These extraneous calculations reduceoverall graphics performance. Also, a DP may need only a small subset ofthe derived items supported for the given changes to the context(s).

Thus, prior art computer graphics systems suffer from numerousdeficiencies.

SUMMARY OF THE INVENTION

A method and apparatus in a computer system, for maintaining a computergraphics interface between an application program and device pipeline.The computer system implements a view model including a plurality ofcoordinate systems. An acyclic graph is stored, wherein the acyclicgraph represents dependencies between various items in each of theplurality of coordinate systems. Then, upon a creation of an item in afirst coordinate system of the plurality of coordinate systems, anobject is associated with the item. The object associates all deriveditems from the item in others of the plurality of coordinate systems.The object includes a first flag for indicating whether the current itemis valid within the first coordinate system. The object further includesa second flag for indicating that at least one of the derived items isnot valid in its respective coordinate system. Upon requests for theitem by the application program, it is determined whether the item isvalid, and if not, then the acyclic graph is descended to determine whenone of the derived items is valid. When one valid item is found, theitem is calculated and it is indicated that the one item is valid. Then,the acyclic graph is ascended, each derived item is calculated, and itis indicated that each derived item is valid until reaching therequested item. Then, the requested item is calculated, indicating thatit is valid and the requested item is presented to the applicationprogram. The storage of the object further allows entry of geometricdata from multiple coordinate systems, and provides a fast test toindicate that derived items are invalid.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example and notlimitation in the figures of the accompanying in which like referencesindicate similar elements and in which:

FIG. 1 illustrates a system upon which one embodiment of the presentinvention may be implemented.

FIG. 2 illustrates the software architecture used in implementedembodiments of the present invention, including an application program,the device interface and device pipelines.

FIG. 3 illustrates a view model used in implemented embodiments of thepresent invention.

FIG. 4 illustrates the set of objects used in implemented embodiments ofthe present invention.

FIGS. 5a and 5b illustrate an acyclic graph used for representingdependencies and derived items in implemented embodiments of the presentinvention.

FIG. 6 illustrates a method performed during the update of items in acurrent view model.

FIGS. 7a and 7b illustrate a method performed when invalid item(s) arerequested by a device pipeline.

DETAILED DESCRIPTION

The present invention describes a computer graphics system whichimproves performance by setting values in specified coordinate systems,and only calculating derived items from those values at such time asabsolutely necessary. In the following description, for the purposes ofexplanation, certain specific embodiments are set forth describingspecific signals, representations of data, specific hardware platformsupon which certain components may be implemented, and method steps, inorder to provide a thorough understanding of the present invention. Itwill be apparent to one skilled in the art, however, that the presentinvention may be practiced without some of the specific details. Also,in the following description, certain well known circuits and certainmethod steps are illustrated in block-diagram form in order to notunnecessarily obscure the present invention.

A portion of the disclosure of this patent document contains materialwhich is subject to copyright protection and to which a claim ofcopyright protection is made. The copyright owner has no objection tothe facsimile reproduction by anyone of the patent disclosure, as itappears in the Patent and Trademark Office patent files or records, butotherwise reserves all copyrights and similar rights whatsoever.©Copyright 1993 Sun Microsystems Inc., all rights reserved.

System in One Embodiment of the Present Invention

Referring to FIG. 1, a system upon which one implementation of thepresent invention is implemented is shown as 100. 100 comprises a bus orother communication means 101 for communicating information, and aprocessing means 102 coupled with bus 101 for processing information.System 100 further comprises a random access memory (RAM) or othervolatile storage device 104 (referred to as main memory), coupled to bus101 for storing information and instructions to be executed by processor102. Main memory 104 also may be used for storing temporary variables orother intermediate information during execution of instructions byprocessor 102. System 100 also comprises a read only memory (ROM) and/orother static storage device 106 coupled to bus 101 for storing staticinformation and instructions for processor 102, and a data storagedevice 107 such as a magnetic disk or optical disk and its correspondingdisk drive. Data storage device 107 is coupled to bus 101 for storinginformation and instructions. This may be used for storage of thedatabases to be described here which maintain information aboutcurrently defined problem descriptions using commercially availablesoftware products.

System 100 may further be coupled to a display device 121, such as acathode ray tube (CRT) or liquid crystal display (LCD) coupled to bus101 for displaying information to a computer user. Such a display 121may further be coupled to bus 101 via a frame buffer 110, whichinformation such as a single or multiple frames or images for displayupon display device 121. An alphanumeric input device 122, includingalphanumeric and other keys, may also be coupled to bus 101 forcommunicating information and command selections to processor 102. Anadditional user input device is cursor control 123, such as a mouse, atrackball, stylus, or cursor direction keys, coupled to bus 101 forcommunicating direction information and command selections to processor102, and for controlling cursor movement on display 121.

Note, also, that any or all of the components of system 100 andassociated hardware may be used in various embodiments, however, it canbe appreciated that any configuration of the system may be used forvarious purposes according to the particular implementation.

In one embodiment, system 100 is one of the Sun Microsystems® brandfamily of workstations such as the SPARCstation workstationsmanufactured by Sun Microsystems® of Mountain View, Calif. Processor 102may be one of the SPARC brand microprocessors manufactured by SunMicrosystems® of Mountain View, Calif. (Sun Microsystems® of MountainView, Calif.).

Note that the following discussion of various embodiments discussedherein will refer specifically to a series of routines which aregenerated in a high-level programming language (e.g., the C++ language)and compiled, linked, and then run as object code in system 100 duringrun-time, for example by the SPARCompiler available from SunMicrosystems® of Mountain View, Calif. Specifically, the presentinvention is operative in conjunction with various software libraries,such as the Solaris® XGL computer graphics package available fromSunSoft, Inc. of Mountain View, Calif. (Sun, Sun Microsystems, XGL, andSolaris are trademarks of Sun Microsystems of Mountain View, Calif.SPARC and SPARCstation are trademarks of SPARC International, Inc. andare licensed exclusively to Sun Microsystems). It can be appreciated byone skilled in the art, however, that the following methods andapparatus may be implemented in special purpose hardware devices, suchas discrete logic devices, large scale integrated circuits (LSI's),application-specific integrated circuits (ASIC's), or other specializedhardware. The description here has equal application to apparatus havingsimilar function.

Software Architecture

Implemented embodiments of the present invention run within a windowenvironment managed by an X11-R5 compatible server, such as theX11/NeWS™ servers within the Sun® Microsystems brand OpenWindows™environment. Application programs perform various graphics operations bycalling graphics operations from an Application Program interface (API).The API provides the functionality here to support derived items. TheAPI's which may be used in various implementations of the presentinvention include those using a GKS and PHIGS interface.

As illustrated in FIG. 2, the software architecture in implementedembodiments of the present invention relies upon application programs201 transmitting requests to a device-independent graphics framework 202which, based on calls from application programs 201, provides certaininformation either to a device pipeline 204 or a software pipeline 203.In this way, when graphics primitives are invoked by an applicationprogram, calculations and other operations required by the primitivesmay be performed and the geometry required by the program may be passedto either the device pipeline 204 or the software pipeline 203. As willbe discussed, if operations do not need to be performed immediately,that is, they can be deferred to some later time, the framework 202 willnot pass any data directly to the pipelines 203 or 204. The frameworkwill therefore perform operations such as calculations and/or passingdata to the pipelines only when absolutely required and when it is mostefficient. In this way, performance of the overall system is improved.

In implemented embodiments, a view model is a series of coordinatesystems in which various parameters may be specified. One example of aview model which is used in implemented embodiments of the presentinvention is illustrated with reference to FIG. 3. 300 of FIG. 3 shows athree-dimensional view model which includes a plurality of coordinatesystems at which various attributes may be set. In FIG. 3, coordinatesystems are shown with a simple abbreviation (e.g. GMC for Global ModelCoordinates, as discussed in the background above), and transforms ormatrices used for calculating items in one coordinate system to anotherare shown with an abbreviation surrounded by a square (e.g. the matrix L311 for the MC 301 to GMC 302 transform). These coordinate systems aresimilar in application to those used in other prior art systems,including PHIGS, which is described in Foley, van Dam, Feiner andHughes, Computer Graphics: Principles and Practice (2d Ed. 1990), at pp.279-281. The coordinate systems used in implemented embodiments of thepresent invention include those available to and settable by applicationprograms (known as "API-visible" coordinate systems and transforms)which are shown to the left of the partition line 350 in FIG. 3, andthose used internally in the embodiments of the present invention shownto the right of the partition line 350.

For example, as shown in FIG. 3, the application program may specifyattributes in Global Model Coordinates 302 which may be then transformedby the matrix known as the K or Global Model transform 312. In addition,certain coordinate systems use transforms which are visible to theapplication program and those which are not. For example, certain itemsin the Virtual Device Coordinate system 304 relies upon data transformedfrom the World Coordinate system 303 by the View Transform 313, and datain Lighting Coordinates 361 transformed by the QG transform 352. Modeltransforms provided in implemented embodiments of the present inventionmay also be concatenated for transforming items created in a firstcoordinate system and a second succeeding coordinate system. Forexample, items created in Model Coordinates 301 may be transformed intoitems residing in World Coordinates 303 by concatenating the matrix 311with the matrix 312. Thus a single transform, the MC-to-WC transform maybe created which is used for transforming items in Model Coordinates 301to items in World Coordinates 303.

View Model Derived Data

Items calculated from the view model attributes specified by theapplication are known as derived items.

Implemented embodiments of the present invention define a conceptualview model consisting of a number of coordinate systems wherein anapplication at layer 201 in FIG. 2 can specify certain operations.Implemented embodiments of the present invention provide a facility inthe pipeline interface named View Model Derived data to assist pipelineswith implementation of the view model's operations.

Derived data maintains a cache of items derived from a context's viewmodel attributes. The derived items include Transforms, such as thosediscussed above, for mapping geometry between coordinate systems as wellas items in various coordinate systems such as the view clip bounds,lights, eye positions or eye vectors, model clip planes, and depth cuereference planes. For example, derived data calculates the VDC-to-DCTransform from the Context attributes for the VDC map, VDC orientation,VDC window, DC viewport, and jitter offset, and the Device attribute forDC orientation. Thus, a derived item can depend on only API-setattributes, on only derived items, or on a combination or both.

Components of the Derived Data Mechanism

Implemented embodiments of the present invention use an object-orientedapproach to supporting the implementation of derived data. The centralobject of the derived data mechanism is the view cache object. The viewcache consists of derived items and functions for deferred evaluation ofthe items. Each Context has a pointer to its own view cache, whichmaintains the derived items specific to that Context. A view cacheobject is created at Context creation time by a constructor in theContext object.

The Context constructor creates a set of Transform objects thatrepresent its default transformations (Local Model Transform, etc.) andcreates the view cache object. The view cache constructor createsinternal Transforms that are needed by derived data. The view cacheconstructor also creates a set of view group configuration objects, eachof which represents a coordinate system from which geometry can enter aLI-1 (the loadable interface) primitive.

The view group interface object is the pipeline's interface to the viewmodel derived data. It informs a pipeline when derived items havechanged as a result of either the application changing a view modelattribute or a pipeline changing the coordinate system from whichgeometry enters the next primitive. The view group interface constructoris created when the pipeline context object is created.

The view group interface has functions for creating and destroying viewconcern objects. A view concern object is a description of all thederived items about which a pipeline is concerned. A pipeline may createas many view concern objects as it needs.

FIG. 4 illustrates the set of objects in the derived data mechanism in athree-dimensional context. This example shows a 3D Context 420 with oneview concern object for stroke primitives 427 and another for surfaceprimitives 426. Note that for 3D Contexts, them are five view groupconfiguration ViewCache objects 400. The derived items in this figureinclude the transforms, for various coordinate systems, 401-405. A viewcache object consists of derived items and functions for deferredevaluation of the items. Each Context has a pointer to its own viewcache object, which maintains the derived items specific to thatContext.

A view group configuration object (e.g. each of items 400) holds staticconfiguration information for each coordinate system from which geometrycan enter LI-1. Each view cache has an array of view group configurationobjects, one for each coordinate system that the view cache supports. A2D view cache supports MC, VDC, CC, and DC. A 3D view cache supportsthese four as well as LC, as illustrated in FIG. 3. The configurationinformation is static: it is invariant once initialized and is common toall view caches of a particular dimension.

A view group interface object (e.g. 424 or 425) is a pipeline'sinterface to the view model derived data. This object informs a pipelinewhen derived items have changed as a result of either the applicationchanging a view model attribute or a pipeline changing the coordinatesystem from which geometry enters the next LI-1 primitive. The viewgroup interface also maintains functions for returning the itemsappropriate to the current coordinate system.

A view concern object (e.g. 426 or 427) is a description of all thederived items whose changes a pipeline is concerned with. This object isa parameter of the view group interface's fast test for changes toderived items.

Each pipeline has a pointer to a view group interface object (e.g. 424or 425). The view group interlace has functions for creating anddestroying view concern objects. A pipeline may create as many viewconcern objects as it needs. For example, it can have one for strokeprimitives and one for surface primitives (e.g. 426 and/or 427).

How Derived Data Gets Information From the Context

There are two ways that Context state can change: the application candirectly set a Context attribute, or the application can change anobject used by the Context, causing the object to send a message to theContext about the change. Either of these two types of changes can causederived data to change.

The Context has a number of attributes that the application can set,among which are the view model attributes. For example, if theapplication changes the VDC window using a function object₋₋ set() toset a context variable CTX₋₋ VDC₋₋ WINDOW, a number of derived itemsthat are dependent on the value of the VDC window become invalid. But,because the changes are evaluated lazily, the derived data items are notrecalculated until the pipeline requests the items.

If the member datum in the Context of the VDC window is changed, theContext informs the view cache object that the application changed theVDC window by calling a function in the view cache object. This functioninvalidates the derived items that depend on the VDC window. A set ofbits records which derived items changed.

Some Context attributes that are objects, such as Lights, Transforms, orthe Device, can change, causing derived data items to change. Forexample, if an application gets the Local Model Transform and changesit, the Transform sends a message to each Context that uses theTransform. If the Context is interested in the change to the Transform,it will call a view cache function to invalidate derived items thatdepend on the Local Model Transform. This process is similar for changesto Lights and for Device resizes.

Derived Data and the Interface Manager

Derived data changes are propagated from the Context's view cache to thepipeline's view group interface object by the interface manager. Whenthe Context stores changes in the view cache object, the information isnot sent to the pipelines until the interface manager is invoked atrendering time. At this time, the interface manager tells the view groupinterface to mark its set of change bits to reflect the changes in theview cache object. The view group interface object accesses the deriveddata information in the view cache object to get the current change bitsand marks its bits. The pipeline will call the functionchangedComposite() to determine whether a derived item has changed. IfchangedComposite() returns TRUE, the pipeline checks the changefunctions for individual items to determine which ones changed.

Acyclic Graph

Implemented embodiments of the present invention use an acyclic graph todetermine which item(s) are derived from other item(s). As discussedpreviously, these include transforms and other items, including viewerposition, light position, clip planes, viewports, etc. Each derived itemdeclined in the system in implemented embodiments contains references,in the form of direct function calls for evaluating other items whichhave validity flags. In this way, when a view model attribute ismodified by the application program, derived items dependent upon thatattribute change, are invalidated during the change. No calculations areperformed at the time of an attribute change. Once the device pipelinerequests one of the invalid derived items, then the calculations may beperformed. This is performed by descending the acyclic graph until validitem(s) are reached, and then calculating invalid item(s) back up theacyclic graph, clearing invalid flags for the item(s) until the itemrequested is reached, whose invalid flag is then cleared.

The acyclic directed graph describes the derived items that becomeinvalid upon a change in value to any view model attribute. It alsodescribes the dependencies of each derived item on other items, andhence an optimal evaluation traversal for any derived item requested bya pipeline. The acyclic graph used in implemented embodiments of thepresent invention is illustrated with reference to FIGS. 5a and 5b.Although FIGS. 5a and 5b illustrate a complex series ofinterdependencies used in derived data in one implemented embodiment inorder to determine whether item(s) are valid/invalid, and/or have to berecalculated, it can be appreciated by one skilled in the arts that asystem using a different view model than that described with referenceto FIG. 3 may use a different acyclic directed graph. It is important,however, that the dependencies be represented in some form (e.g. a datastructure such as a linked list, an array or series of direct functioncalls, etc.) in some manner so that the advantages of derived data maybe exploited.

In the acyclic directed graph represented in FIGS. 5a and 5b,dependencies are represented in the direction of the arrows and,therefore, the order for evaluating derived items is opposite thedirection of the arrows. Also, although direct function calls are usedin implemented embodiments for the acyclic directed graph, it can beappreciated that in alternative embodiments that pointers, indices orother references can be used to determine derived items, and whether thederived item(s) have been updated.

In the graph, the matrices required by specific coordinate systems areshown in table 1 below. As can be appreciated by one skilled in the art,the matrices L and K change frequently because their correspondingcoordinate systems (Model Coordinates and Global Model Coordinates) aremost frequently updated by an application program:

                                      TABLE 1                                     __________________________________________________________________________    Coordinate System                                                                         Matrices    Purpose                                               __________________________________________________________________________    MC- > GMC (local)                                                                         L           API modeling                                          GMC- > WC (Global)                                                                        K           API modeling                                          WC- > VDC (View)                                                                          V = EQG     API viewing, to be factored                           VDC- > DC (Device)                                                                        D           Device mapping (derived from API)                     DC- > VDC   D.sup.-1    Intermediate step                                     VDC- > CC   C           View clip planes                                      CC- > VDC   C.sup.-1    Intermediate step                                     VDC-WC      ((QG).sup.-1) )E.sup.-1)                                                                  Intermediate step                                     WC- > CC    VC          Model clip planes                                     CC- > WC    (C.sup.-1) ((QG).sup.-1) (E.sup.-1)                                                       Model clip planes                                     WC- > DC    VD          Model clip planes                                     DC- > WC    (D.sup.-1) ((QG).sup.-1) (E.sup.-1)                                                       Model clip planes                                     DC- > MC    (D.sup.-1) ((QG).sup.-1) (E.sup.-1)N                                                      Eye, facet nominal                                    DC- > LC    (D.sup.-1) ((QG).sup.-1))                                                                 Eye                                                   MC- > WC (Model)                                                                          M = LK      Lights, model clip planes, eye                        WC- > MC (Normal)                                                                         N =  M.sup.-1                                                                             Lights, model clip planes, eye                        WC- > LC    E           Lights                                                LC- > WC    E.sup.-1    Lights                                                MC- > DC    M(VD)       Points                                                MC- > CC    M(VC)       Points                                                CC- > DC    (C.sup.-1)D Points                                                LC- > VDC   QG          Intermediate Step (sparse)                            VDC- > LC   (QG).sup.-1 Intermediate Step (sparse)                            CC- > LC    (C.sup.-) (QG).sup.-1)                                                                    Points                                                LC- > DC    (QG)D       Points                                                MC- > LC    ME          Points                                                LC- > MC    (E.sup.-1)N Normals                                               __________________________________________________________________________

Note that similar labels in FIGS. 5a and 5b refer to the same items, andthe graph represented has been partitioned into two figures forconvenience.

Fast Test

Implemented embodiments of the present invention also use a fast test inorder to enable the determination of whether derived items are valid orinvalid. The fast test is also known and referred to as thechangedComposite() function in implemented embodiments of the presentinvention. If the fast test yields that a particular derived item ischanging because an item upon which that item is derived changed, thenindividual items are checked for changes. The pipeline requests changeditems, causing a traversal of the directed graph, in the mannerdiscussed above, until an item is reached that is valid, and the invaliditem(s) are calculated back through the graph until the requested itemis reached, which may be then calculated.

Derived data allows device pipelines to specify the derived items aboutwhich they are concerned with changes so that irrelevant changes arefiltered out. Each pipeline has an interface to the derived items in thecache. The interface consists of two flag words. A bit of eachrepresents a derived item. One flag word stores changes to items causedby changes to API view model attributes. The other stores unacknowledgedchanges in the current coordinate system from which geometry enters.These two words are used in the fast test so that a primitive canquickly check whether a pipeline needs to reload derived items. The bitsin the first flag word are updated when the application sets a viewmodel attribute. The second flag word is updated by a precomputed table:each entry is for a specific pair of coordinate systems. When a pipelinechanges coordinate systems, say from MC to LC, the precomputed bitpattern is taken from the precomputed table and combined with the secondflag word.

The interface has a pointer for each derived item to an evaluationfunction in the cache. For example, two derived items are the MC-to-CCmatrix and the LC-to-CC matrix. If the current coordinate system is MC,the interface sets the MC-to-CC pointer to the MC-to-CC evaluationfunction. If a pipeline changes the current coordinate system to LC, theinterface sets the MC-to-CC pointer to the LC-to-CC evaluation function.This allows a pipeline to get and reload the correct matrix without theburden of being aware of the current coordinate system. This is anexample of a mapping for supporting entry of geometry from multiplecoordinate systems.

Detail of Implementation

The following is a detail of an example implementation of 2-dimensionalgeometry in a graphics library known as XGL including references tosource code wherein the source code language shown is C++.

1. Creation of a View Cache

An XGL application creates a 2D graphics Context. In turn, each Contextcreates its own View Cache. The View Cache contains an array of ViewGroup Configurations (one per coordinate system from which geometryenters LI-1). The constructor for XglViewCache2d initializes theinformation in each View Group Configuration, which consists of a flagtable and a set of pointers to evaluation functions. There is one tableelement and one pointer for each derived item.

1(a). Indices and Bits Corresponding to Derived Items

Each derived item is assigned a bit in a view flag word. The bit indexstarts at 0 and increases incrementally (0, 1, 2 . . . ).

    ______________________________________                                        enum Xgli.sub.-- view.sub.-- idx.sub.-- a {                                   // Derived data                                                               XGLI.sub.-- VIEW.sub.-- IDX.sub.-- A.sub.-- MC.sub.-- TO.sub.-- DC = 0,       XGLI.sub.-- VIEW.sub.-- IDX.sub.-- A.sub.-- MC.sub.-- TO.sub.-- CC,           XGLI.sub.-- VIEW.sub.-- IDX.sub.-- A.sub.-- CC.sub.-- TO.sub.-- DC,           XGLI.sub.-- VIEW.sub.-- IDX.sub.-- A.sub.-- MC.sub.-- TO.sub.-- WC,           XGLI.sub.-- VIEW.sub.-- IDX.sub.-- A.sub.-- YDC.sub.-- TO.sub.-- CC,          XGLI.sub.-- VIEW.sub.-- IDX.sub.-- A.sub.-- CC.sub.-- TO.sub.-- VDC,          XGLI.sub.-- VIEW.sub.-- IDX.sub.-- A.sub.-- WC.sub.-- TO.sub.-- CC,           XGLI.sub.-- VIEW.sub.-- IDX.sub.-- A.sub.-- VDC.sub.-- TO.sub.-- DC,          XGLI.sub.-- VIEW.sub.-- IDX.sub.-- A.sub.-- DC.sub.-- TO.sub.-- VDC,          XGLI.sub.-- VIEW.sub.-- IDX.sub.-- A.sub.-- WC.sub.-- TO.sub.-- DC,           XGLI.sub.-- VIEW.sub.-- IDX.sub.-- A.sub.-- DC.sub.-- TO.sub.-- CC,           XGLI.sub.-- VIEW.sub.-- IDX.sub.-- A.sub.-- MC.sub.-- TO.sub.-- VDC,          XGLI.sub.-- VIEW.sub.-- IDX.sub.-- A.sub.-- DC.sub.-- TO.sub.-- MC,           XGLI.sub.-- VIEW.sub.-- IDX.sub.-- A.sub.-- YC.sub.-- TO GMC,                 XGLI.sub.-- VIEW.sub.-- IDX.sub.-- A.sub.-- GMC.sub.-- TO.sub.-- WC,          XGLI.sub.-- VIEW.sub.-- IDX.sub.-- A.sub.-- WC.sub.-- TO.sub.-- VDC,          XGLI.sub.-- VIEW.sub.-- IDX.sub.-- A.sub.-- VCLIP.sub.-- BOUNDS.sub.--        VDC,                                                                          XGLI.sub.-- VIEW.sub.-- IDX.sub.-- A.sub.-- VCLIP.sub.-- BOUNDS.sub.--        CC,                                                                           XGLI.sub.-- VIEW.sub.-- IDX.sub.-- A.sub.-- VCLIP.sub.-- BOUNDS.sub.--        DC,                                                                           XGLI.sub.-- VIEW.sub.-- IDX.sub.-- A.sub.-- VCLIP.sub.-- BOUNDS.sub.--        MC,                                                                           XGLI.sub.-- VIEW.sub.-- IDX.sub.-- A.sub.-- VCLIP.sub.-- ACTIVITY,            XGLI.sub.-- VIEW.sub.-- IDX.sub.-- A.sub.-- VIEWPORT.sub.-- DC                };                                                                            ______________________________________                                    

Then the bit assigned to a derived item is obtained by shifting 1 to theleft by the index.

    __________________________________________________________________________    static const Xg1.sub.-- usgn32                                                            XGLI.sub.-- VIEW.sub.-- A.sub.-- MC.sub.-- TO.sub.-- DC                       = 1 << XGLI.sub.-- VIEW.sub.-- IDX.sub.-- A.sub.-- MC.sub.--                  TO.sub.-- DC;                                                     static const Xg1.sub.-- usgn32                                                            XGLI.sub.-- VIEW.sub.-- A.sub.-- MC.sub.-- TO.sub.-- CC                       = 1 << XGLI.sub.-- VIEW.sub.-- IDX.sub.-- A.sub.-- MC.sub.--                  TO.sub.-- CC;                                                     static const Xg1.sub.-- usgn32                                                            XGLI.sub.-- VIEW.sub.-- A.sub.-- CC.sub.-- TO.sub.-- DC                       = 1 << XGLI.sub.-- VIEW.sub.-- IDX.sub.-- A.sub.-- CC.sub.--                  TO.sub.-- DC;                                                     static const Xg1.sub.-- usgn32                                                            XGLI.sub.-- VIEW.sub.-- A.sub.-- MC.sub.-- TO.sub.-- WC                       = 1 << XGLI.sub.-- VIEW.sub.-- IDX.sub.-- A.sub.-- MC.sub.--                  TO.sub.-- WC;                                                     static const Xg1.sub.-- usgn32                                                            XGLI.sub.-- VIEW.sub.-- A.sub.-- VDC.sub.-- TO.sub.-- CC                      = 1 << XGLI.sub.-- VIEW.sub.-- IDX.sub.-- A.sub.-- VDC.sub.--                 TO.sub.-- CC;                                                     static const Xg1.sub.-- usgn32                                                            XGLI.sub.-- VIEW.sub.-- A.sub.-- CC.sub.-- TO.sub.-- VDC                      = 1 << XGLI.sub.-- VIEW.sub.-- IDX.sub.-- A.sub.-- CC                         TO.sub.-- VDC;                                                    static const Xg1.sub.-- usgn32                                                            XGLI.sub.-- VIEW.sub.-- A.sub.-- WC.sub.-- TO.sub.-- VDC                      = 1 << XGLI.sub.-- VIEW.sub.-- IDX.sub.-- A.sub.-- WC.sub.--                  TO.sub.-- CC;                                                     static const Xg1.sub.-- usgn32                                                            XGLI.sub.-- VIEW.sub.-- A.sub.-- VDC.sub.-- TO.sub.-- DC                      = 1 << XGLI.sub.-- VIEW.sub.-- IDX.sub.-- A.sub.-- VDC.sub.--                 TO.sub.-- DC;                                                     static const Xg1.sub.-- usgn32                                                            XGLI.sub.-- VIEW.sub.-- A.sub.-- DC.sub.-- TO.sub.-- VDC                      = 1 << XGLI.sub.-- VIEW.sub.-- IDX.sub.-- A.sub.-- DC.sub.--                  TO.sub.-- VDC;                                                    static const Xg1.sub.-- usgn32                                                            XGLI.sub.-- VIEW.sub.-- A.sub.-- WC.sub.-- TO.sub.-- DC                       = 1 << XGLI.sub.-- VIEW.sub.-- IDX.sub.-- A.sub.-- WC.sub.--                  TO.sub.-- DC;                                                     static const Xg1.sub.-- usgn32                                                            XGLI.sub.-- VIEW.sub.-- A.sub.-- DC.sub.-- TO.sub.-- CC                       = 1 << XGLI.sub.-- VIEW.sub.-- IDX.sub.-- A.sub.-- DC.sub.--                  TO.sub.-- CC;                                                     static const Xg1.sub.-- usgn32                                                            XGLI.sub.-- VIEW.sub.-- A.sub.-- MC.sub.-- TO.sub.-- VDC                      = 1 << XGLI.sub.-- VIEW.sub.-- IDX.sub.-- A.sub.-- MC.sub.--                  TO.sub.-- VDC;                                                    static const Xg1.sub.-- usgn32                                                            XGLI.sub.-- VIEW.sub.-- A.sub.-- DC.sub.-- TO.sub.-- MC                       = 1 << XGLI.sub.-- VIEW.sub.-- IDX.sub.-- A.sub.-- DC.sub.--                  TO.sub.-- MC;                                                     static const Xg1.sub.-- usgn32                                                            XGLI.sub.-- VIEW.sub.-- A.sub.-- MC.sub.-- TO.sub.-- MC                       = 1 << XGLI.sub.-- VIEW.sub.-- IDX.sub.-- A.sub.-- MC.sub.--                  TO.sub.-- MC;                                                     static const Xg1.sub.-- usgn32                                                            XGLI.sub.-- VIEW.sub.-- A.sub.-- GMC.sub.-- TO.sub.-- WC                      = 1 << XGLI.sub.-- VIEW.sub.-- IDX.sub.-- A.sub.-- GMC.sub.--                 TO.sub.-- WC;                                                     static const Xg1.sub.-- usgn32                                                            XGLI.sub.-- VIEW.sub.-- A.sub.-- WC.sub.-- TO.sub.-- VDC                      = 1 << XGLI.sub.-- VIEW.sub.-- IDX.sub.-- A.sub.-- WC.sub.--                  TO.sub.-- VDC;                                                    static const Xg1.sub.-- usgn32                                                            XGLI.sub.-- VIEW.sub.-- A.sub.-- VCLIP.sub.-- BOUNDS.sub.--                   VDC                                                                           = 1<<XGLI.sub.-- VIEW.sub.-- IDX.sub.-- A.sub.-- VCLIP.sub.--                 BOUNDS.sub.-- VDC;                                                static const Xg1.sub.-- usgn32                                                            XGLI.sub.-- VIEW.sub.-- A.sub.-- VCLIP.sub.-- BOUNDS.sub.--                   CC                                                                            = 1 << XGLI.sub.-- VIEW.sub.-- IDX.sub.-- A.sub.-- VCLIP.sub.-                - BOUNDS.sub.-- CC;                                               static const Xg1.sub.-- usgn32                                                            XGLI.sub.-- VIEW.sub.-- A.sub.-- VCLIP.sub.-- BOUNDS.sub.--                   DC                                                                            = 1 << XGLI.sub.-- VIEW.sub.-- IDX.sub.-- A.sub.-- VCLIP.sub.-                - BOUNDS.sub.-- DC;                                               static const Xg1.sub.-- usgn32                                                            XGLI.sub.-- VIEW.sub.-- A.sub.-- VCLIP.sub.-- BOUNDS.sub.--                   MC                                                                            = 1 << XGLI.sub.-- VIEW.sub.-- IDX.sub.-- A.sub.-- VCLIP.sub.-                - BOUNDS.sub.-- MC;                                               static const Xg1.sub.-- usgn32                                                            XGLI.sub.-- VIEW.sub.-- A.sub.-- VCLIP.sub.-- ACTIVITY                        = 1 << XGLI.sub.-- VIEW.sub.-- IDX.sub.-- A.sub.-- VCLIP.sub.-                - ACTIVITY;                                                       static const Xg1.sub.-- usgn32                                                            XGLI.sub.-- VIEW.sub.-- A.sub.-- VIEWPORT.sub.-- DC                           = 1 << XGLI.sub.-- VIEW.sub.-- IDX.sub.-- A.sub.-- VIEWPORT                   DC;                                                               __________________________________________________________________________

Wherein Xgl₋₋ usgn32 is an unsigned 32-bit word.

1(b). Initialization of a View Cache's Array of View GroupConfigurations

Each flag table element in the View Group Configuration correspond to anindex shown above. For example, XGLI₋₋ VIEW₋₋ IDX₋₋ A₋₋ MC₋₋ TO₋₋ CC is1 so the flag table element whose index is 1 corresponds to the MC-to-CCTransform.

A View Group Configuration stores the mappings for supporting entry ofgeometry from a particular coordinate system. An example of a mapping:when the current coordinate system is VDC and a pipeline requests theMC-to-CC Transform, then derived data should return the VDC-to-CCTransform. So in the View Group Configuration for VDC, MC-to-CC maps toVDC-to-CC. This requires the following initialization in the form of amacro for simplifying the definition of all the mappings in the viewgroup configurations.

    __________________________________________________________________________    // CACHE2D.sub.-- SET.sub.-- DD sets up the flag table and the                configuration for derived data.                                               // COORD.sub.-- SYS is the coordinate system of the incoming geometry.        // DOMAIN is the flag mask of the virtual derived data item.                  // RANGE is the flag mask of the actual derived data item adjusted for        the                                                                           // coordinate system.                                                         // DD.sub.-- PTR is the name of the pointer to the evaluation function        for the                                                                       // derived data item adjusted for the coordinate system.                      // EVAL.sub.-- FUNC is the name of the evaluation function for the            derived data item                                                             // adjusted for the coordinate system.                                        //                                                                            #define CACHE2D.sub.-- SET.sub.-- DD(COORD.sub.-- SYS, DOMAIN, RANGE,         DD.sub.-- PTR, EVAL.sub.-- FUNC)                                              setFlagTable (config[COORD.sub.-- SYS].flagTable, DOMAIN, RANGE);             config[COORD.sub.-- SYS].DD.sub.-- PTR = Xg1ViewCache2d: :EVAL.sub.--         FUNC;                                                                         __________________________________________________________________________

For example, the following macro invocation is in the constructorfunction XglViewCache2d::XglViewCache2d:

    __________________________________________________________________________    CACHE2D.sub.-- SET.sub.-- DD(XGLI.sub.-- LI1.sub.-- 2D.sub.-- COORD.sub.--     SYS.sub.-- VDC, XGLI.sub.-- VIEW.sub.-- A.sub.-- MC.sub.-- TO.sub.--         CC,                                                                           XGLI.sub.-- VIEW.sub.-- A.sub.-- VDC.sub.-- TO.sub.-- CC, ptrMcToCc,          evalVdcToCc)                                                                  __________________________________________________________________________

The C++ preprocessor expands this to:

    __________________________________________________________________________    setFlagtable (config [XGLI.sub.-- LI1.sub.-- 2D.sub.-- COORD.sub.--           SYS.sub.-- VDC] flagTable,                                                    XGLI.sub.-- VIEW.sub.-- A.sub.-- MC.sub.-- TO.sub.-- CC, XGLI.sub.--          VIEW.sub.-- A.sub.-- VDC.sub.-- TO.sub.-- CC);                                config[XGLI.sub.-- LI1.sub.-- 2D.sub.-- COORD.sub.-- SYS.sub.-- VDC].ptrMc    ToCc = Xg1ViewCache2d::evalVdcToCc;                                           __________________________________________________________________________

This is the configuration that accomplishes the mapping. The flag tablewith the element corresponding to XGLI₋₋ VIEW₋₋ A₋₋ MC₋₋ TO₋₋ CC is setto XGLI₋₋ VIEW₋₋ A₋₋ VDC₋₋ TO₋₋ CC. The pointer to the function forgetting the MC-to-CC Transform is set to the evaluation function forVDC-to-CC.

The following function sets the flag table:

    ______________________________________                                        // setFlagTable sets one entry of a flag table in a configuration.            // domain is a flag mask unadjusted for coordinate system.                    // range is a flag mask adjusted for coordinate system.                       //                                                                            void Xg1ViewCache2d::setFlagTable (Xg1.sub.-- usgn32 flag.sub.-- table[],                       const Xg1.sub.-- usgn32 domain,                                               const Xg1.sub.-- usgn32 range)                              {                                                                             // TRACE(*Xg1ViewCache2d::setFlagTable*);                                     flag.sub.-- table [leastSigOnBitPosition (domain)] = range;                   }                                                                             ______________________________________                                    

leastSigOnBitPosition() is a function that returns the index of theleast significant bit which is on (i.e. set to 1). In the example above,this converts XGLI₋₋ VIEW₋₋ A₋₋ MC₋₋ TO₋₋ CC to XGLI₋₋ VIEW₋₋ IDX₋₋ A₋₋MC₋₋ TO₋₋ CC, which is the index into the flag table.

Mappings must be set up for each derived item supported. One set ofmappings is required for each coordinate system supported for whichthere is a View Group Configuration.

In 2D, derived data supports four coordinate systems from which geometrycan enter LI-1:

    ______________________________________                                        //                                                                            // LI1 accepts geometry from the following 2D Coordinate                      Systems                                                                       //                                                                            enum Xg1i.sub.-- li1.sub.-- 2d.sub.-- coord.sub.-- sys {                      XGLI.sub.-- LI1.sub.-- 2D.sub.-- COORD.sub.-- SYS.sub.-- MC = 0,              XGLI.sub.-- LI1.sub.-- 2D.sub.-- COORD.sub.-- SYS.sub.-- VDC,                 XGLI.sub.-- LI1.sub.-- 2D.sub.-- COORD.sub.-- SYS.sub.-- CC,                  XGLI.sub.-- LI1.sub.-- 2D.sub.-- COORD.sub.-- SYS DC                          };                                                                            ______________________________________                                    

The array of View Group Configurations in the View Cache is static. Onceinitialized, the mappings never change again. The array is also sharedby all View Cache objects so it needs to be initialized only when thefirst View Cache object is created.

1(c). Initialization of the Coordinate System Change Flag

A Device pipeline usually retains state. For example, a graphicsaccelerator may have hardware registers for storing the matrices of theMC-to-CC and CC-to-DC Transforms. A Dp usually needs to update theregisters when an application changes a view model attribute or when apipeline changes the current coordinate system.

Consider a simple example of 2D annotation text in the softwarepipeline. The application passes a character string and a referencepoint to XGL at the API level. If the device pipeline cannot handleannotation text at LI-1, the software pipeline transforms the referencepoint from MC to VDC, checks that the point is within the view clipbounds, and constructs a polyline description of the text based oninformation stored in font files. Derived data provides functions sothat a primitive can push the current coordinate system onto a stack andset it to another: VDC in the case of annotation text. Then theprimitive can call LI-1 multipolyline. When the multipolyline functionrequests a transform, for example the MC-to-CC Transform, derived datareturns the appropriate transform for the current coordinate system: inthis case, the VDC-to-CC Transform. The LI-1 multipolyline primitivedoesn't need to be aware that the current coordinate system is VDCinstead of MC. When control returns from the LI-1 polyline primitive tothe software pipeline's LI-1 annotation text primitive, the latter canpop the coordinate system to restore the original one (which should beMC).

A pipeline typically changes current coordinate systems when it hasdecomposed a complex primitive into simple primitives in a coordinatesystem other than MC. Then the simple primitives can be sent to theappropriate LI-1 function for further geometry processing and rendering.Derived data simplifies the development effort required to implementLI-1 functions because they can be written as if geometry always entersfrom MC.

The View Cache maintains a matrix of flags to keep track of coordinatesystem changes that may require a pipeline to reload the retained state.The matrix's first index is the previous coordinate system (before thechange); the second is the current coordinate system (after the change).The matrix is asymmetric. The diagonal is NULL (i.e. 0) because thediagonal elements represent no change in the coordinate systems.

The following code in XglViewCache2d::XglViewCache2d() initializes thematrix of coordinate system change flags:

    __________________________________________________________________________    //                                                                            // Initialize matrix of flags indicating the derived data items that may      // have been affected by a change in coordinate systems of the incoming       // geometric data for LI1.                                                    //                                                                            // This matrix gives only an estimate of what may have changed. It may        // generate some false alarms, but it should never miss a change to a         // data item.                                                                 //                                                                            coordSysChangeFlag[XGLI.sub.-- LI1.sub.-- 2D.sub.-- COORD.sub.-- SYS.sub.-    - M][XGLI.sub.-- LI1.sub.-- 2D.sub.-- COORD.sub.-- SYS.sub.-- MC]             = NULL;                                                                       coordSysChangeFlag[XGLI.sub.-- LI1.sub.-- 2D.sub.-- COORD.sub.-- SYS          VDC]]XGLI.sub.-- LI1.sub.-- 2D.sub.-- COORD.sub.-- SYS.sub.-- VDC]            = NULL;                                                                       coordSysChangeFlag[XGLI.sub.-- LI1.sub.-- 2D.sub.-- COORD.sub.-- SYS.sub.-    - CC][XGLI.sub.-- LI1.sub.-- 2D.sub.-- COORD.sub.-- SYS.sub.-- CC]            = NULL;                                                                       coordSysChangeFlag[XGLI.sub.-- LI1.sub.-- 2D.sub.-- COORD.sub.-- SYS.sub.-    - DC][XGLI.sub.-- LI1.sub.-- 2D.sub.-- COORD.sub.-- SYS.sub.-- DC]            = NULL;                                                                       setCoordSysChangeFlag                                                         (XGLI.sub.-- LI1.sub.-- 2D.sub.-- COORD.sub.-- SYS.sub.-- MC,                 config[XGLI.sub.-- LI1.sub.-- 2D.sub.-- COORD.sub.-- SYS.sub.-- MC].flagTa    ble,                                                                          XGLI.sub.-- LI1.sub.-- 2D.sub.-- COORD.sub.-- SYS VDC,                        config[XGLI.sub.-- LI1.sub.-- 2D.sub.-- COORD.sub.-- SYS.sub.-- VDC].flagT    able);                                                                        setCoordSysChangeFlag                                                         (XGLI.sub.-- LI1.sub.-- 2D.sub.-- COORD.sub.-- SYS.sub.-- MC,                 config[XGLI.sub.-- LI1.sub.-- 2D.sub.-- COORD.sub.-- SYS.sub.-- MC].flagTa    ble,                                                                          XGLI.sub.-- LI1.sub.-- 2D.sub.-- COORD.sub.-- SYS.sub.-- CC,                  config[XGLI.sub.-- LI1.sub.-- 2D.sub.-- COORD.sub.-- SYS.sub.-- CC].flagTa    ble);                                                                         setCoordSysChangeFlag                                                         (XGLI.sub.-- LI1.sub.-- 2D.sub.-- COORD.sub.-- SYS.sub.-- MC,                 config[XGLI.sub.-- LI1.sub.-- 2D.sub.-- COORD.sub.-- SYS.sub.-- MC].flagTa    ble,                                                                          XGLI.sub.-- LI1.sub.-- 2D.sub.-- COORD.sub.-- SYS.sub.-- DC,                  config[XGLI.sub.-- LI1.sub.-- 2D.sub.-- COORD.sub.-- SYS.sub.-- DC).flagTa    ble);                                                                         setCoordSysChangeFlag                                                         (XGLI.sub.-- LI1.sub.-- 2D.sub.-- COORD.sub.-- SYS.sub.-- VDC,                config[XGLI.sub.-- LI1.sub.-- 2D.sub.-- COORD.sub.-- SYS.sub.-- VDC].flagT    able,                                                                         XGLI.sub.-- LI1.sub.-- 2D.sub.-- COORD.sub.-- SYS.sub.-- CC,                  config[XGLI.sub.-- LIJ.sub.-- 2D.sub.-- COORD.sub.-- SYS.sub.-- CC].flagTa    ble);                                                                         setCoordSysChangeFlag                                                         (XGLI.sub.-- LI1.sub.-- 2D.sub.-- COORD.sub.-- SYS.sub.-- VDC,                config[XGLI.sub.-- LI1.sub.-- 2D.sub.-- COORD.sub.-- SYS.sub.-- VDC].flagT    able,                                                                         XGLI.sub.-- LI1.sub.-- 2D.sub.-- COORD.sub.-- SYS.sub.-- DC,                  config[XGLI.sub.-- LIJ.sub.-- 2D.sub.-- COORD.sub.-- SYS.sub.-- DC].flagTa    ble);                                                                         setCoordSysChangeFlag                                                         (XGLI.sub.-- LI1.sub.-- 2D.sub.-- COORD.sub.-- SYS.sub.-- CC,                 config[XGLI.sub.-- LI1.sub.-- 2D.sub.-- COORD.sub.-- SYS.sub.-- CC].flagTa    ble,                                                                          XGLI.sub.-- LI1.sub.-- 2D.sub.-- COORD.sub.-- SYS.sub.-- DC,                  config[XGLI.sub.-- LI1.sub.-- 2D.sub.-- COORD.sub.-- SYS.sub.-- DC].flagTa    ble);                                                                         __________________________________________________________________________

XglViewCache2d::setCoordSysChangeFlag() takes as parameters a pair ofcoordinate systems and their corresponding flag tables from the ViewGroup Configurations. It initializes the coordinate system change flagsfor changes from the first coordinate system to the second as well asthe second to the first.

    ______________________________________                                        // setCoordSysChangeFlag sets two entries matrix of coordinate                // system change flags given a pair of coordinate systems. Each               // entry describes the derived data items that map to different               // derived data items. These are the ones thae may need to be                 // reloaded when a change in coordinate systems occurs.                       //                                                                            void Xg1ViewCache2d::setCoordSysChangeFlag                                             (const Xgli.sub.-- li1.sub.-- 2d.sub.-- coord.sub.-- sys                      coord.sub.-- sys.sub.-- 0,                                                    const Xg1.sub.-- usgn32 flag.sub.-- table.sub.-- 0[],                         const xgli.sub.-- li1.sub.-- 2d.sub.-- coord.sub.-- sys                       coord.sub.-- sys.sup.-1,                                                      const Xg1.sub.-- usgn32 flag.sub.-- table.sub.-- l[])                TRACE(*Xg1ViewCache2d::setCoordSysChangeFlag*);                               const Xg1.sub.-- usgn32* flag.sub.-- ptr.sub.-- 0;                            const Xg1.sub.-- usgn32* flag.sub.-- pcr.sub.-- 1;                            Xg1.sub.-- sgn32 j;                                                           coordSysChangeFlag[coord.sub.-- sys.sub.-- 0][coord.sub.-- sys.sub.--         1]=                                                                           coordSysChangeFlag[coord.sub.-- sys.sub.-- 1][coord.sub.-- sys.sub.-- 0]=      NULL;                                                                        flag.sub.-- ptr.sub.-- 0 = flag.sub.-- table.sub.-- 0;                        flag.sub.-- ptr.sub.-- 1 = flag.sub.-- table.sub.-- 1;                        j = XGLI.sub.-- VIEW.sub.-- FLAG.sub.-- TABLE.sub.-- 2D.sub.-- SIZE;          while (j--) {                                                                 if (*flag.sub.-- ptr.sub.-- 0 != *flag.sub.-- ptr.sub.-- 1) {                 coordSysChangeFlag[coord.sub.-- sys.sub.-- 0][coord.sub.-- sys.sub.-- 1]              |= *flag.sub.-- ptr.sub.-- 1;                                coordSysChangeFlag[coord.sub.-- sys.sub.-- 1][coord.sub.-- sys.sub.-- 0]              |= *flag.sub.-- ptr.sub.-- 0;                                }                                                                             flag.sub.-- ptr.sub.-- 0++;                                                   flag.sub.-- ptr.sub.-- 1++;                                                   }                                                                             }                                                                             ______________________________________                                    

Whenever the mappings differ between pair of coordinate systems, thechange flags for the pair are updated by combining the flag word of thenew coordinate system. For example, suppose the first coordinate systemis MC and the second is VDC. If the mappings differ, the change flag forthe transition from MC to VDC must include the flag word for VDC. Forthe transition from VDC to MC, the change flag must include the flagword for MC.

The matrix of coordinate system change flags is static. Onceinitialized, matrix is invariant because the mappings are static. Thematrix is also shared by all View Cache objects so it needs to beinitialized only when the first View Cache object is created.

This matrix is used in the last test calledXglViewGrp2dItf::changedComposite().

2. View Concerns: Creation and Initialization

The Device pipeline (Dp) and Software pipeline (Swp) are the consumersfor view model derived data. A pipeline typically is interested in onlya few items which vary according to the graphics primitive. Surfaceprimitives are more complex than stroke primitives so the former needsmore derived items than the latter. Derived data allows pipelines toexpress concern about changes to items. A pipeline can create as manyView Concerns as it needs. Typically, a pipeline will create one forstroke primitives and one for surface primitives.

To create a View Concern, a pipeline uses logical OR to combine bitscorresponding to the derived items that need to be monitored forchanges. The View Group Interface creates a concern by calling the ViewConcern's constructor, which in turn calls XglViewCache2d::setConcern()to initialize the View Concern:

    __________________________________________________________________________    // setConcern takes a flag with the bits -- corresponding to the derived      // data items of concern to a pipeline -- set to 1. For each coordinate       // system from which geometry can enter LI1, it adjusts the flag for          that                                                                          // particular coordinate system.                                              //                                                                            void Xg1ViewCache2d::setConcern (Xg1ViewConcern2d* concern,                                         const Xg1.sub.-- usgn32 view.sub.-- flag.sub.-- 2d)                           const                                                   TRACE(*Xg1ViewCache2d::setConcern*);                                          setConcernFlag (concern-> concernFlag[XGLI.sub.-- LI1.sub.-- 2D.sub.--        COORD.sub.-- SYS.sub.-- MC],                                                  view.sub.-- flag.sub.-- 2d, config[XGLI.sub.-- LI1.sub.-- 2D.sub.--           COORD.sub.-- SYS.sub.-- MC].flagTable);                                       setConcernFlag (concern-> concernFlag[XGLI.sub.-- LI1.sub.-- 2D.sub.--        COORD.sub.-- SYS.sub.-- VDC],                                                 view.sub.-- flag.sub.-- 2d, config[XGLI.sub.-- LI1.sub.-- 2D.sub.--           COORD.sub.-- SYS.sub.-- VDC].flagTable);                                      setConcernFlag (concern-> concernFlag[XGLI.sub.-- LI1.sub.-- 2D.sub.--        COORD.sub.-- .sub.-- SYS.sub.-- CC],                                          view.sub.-- flag.sub.-- 2d, config[XGLI.sub.-- LI1.sub.-- 2D.sub.--           COORD.sub.-- SYS.sub.-- CC].flagTable);                                       setConcernFlag (concern-> concernFlag[XGLI.sub.-- LI1.sub.-- 2D.sub.--        COORD.sub.-- SYS.sub.-- DC],                                                  view.sub.-- flag.sub.-- 2d, config[XGLI.sub.-- LI1.sub.-- 2D.sub.--           COORD.sub.-- SYS.sub.-- DC].flagTable);                                       }                                                                             __________________________________________________________________________

XglViewCache2d::setConcern() simply callsXglViewCache2d::setConcernFlag() for each of the supported coordinatesystems.

    __________________________________________________________________________    // setConcernFlag takes a flag with the bits -- corresponding to the          derived                                                                       // data items of concern to a pipeline -- set to 1. using a flag table        of                                                                            // a configuration for a particular coordinate system, this function          // adjusts the flag of concerns for the coordinate system.                    //                                                                            void Xg1ViewCache2d::setConcernFlag (Xg1.sub.-- usgn32& concern.sub.--        flag,                                                                                                const Xg1.sub.-- usgn32 view.sub.-- flag.sub.--                               2d,                                                                           const Xg1.sub.-- usgn32 flag.sub.-- table[])                                  const                                                  TRACE(*Xg1ViewCache2d::setConcernFlag*);                                      Xg1.sub.-- sgn32 j;                                                           Xg1.sub.-- usgn32 mc.sub.-- flag;                                             const Xg1.sub.-- usgn32 *flag.sub.-- ptr;                                     concern.sub.-- flag = 0;                                                      flag.sub.-- ptr = flag.sub.-- table;                                          if (view.sub.-- flag.sub.-- 2d) {                                             j = XGLI.sub.-- VIEW.sub.-- FLAG.sub.-- MAX.sub.-- MASK.sub.-- BITS;          mc.sub.-- flag = view.sub.-- flag.sub.-- 2d;                                  while (j--) {                                                                         if (mc.sub.-- flag & 0x1) {                                                     concern.sub.-- flag "=  *flag.sub.-- ptr;                                   }                                                                             mc.sub.-- flag >>= 1;                                                         flag.sub.-- ptr++;                                                    }                                                                             }                                                                             }                                                                             __________________________________________________________________________

So for a particular coordinate system, setConcernFlag() initializes thecoordinate system's concern flag by combining bits obtained as follows.The flag table maps bits set to 1 in the pipeline's view flag to bitsappropriate for the target coordinate system. The mapped bits arecombined to produce the concern flag for the target coordinate system.

3. The Fast Test for Detecting Changes to a Pipeline's Concerns

The View Group Interface is a pipeline's interface to the view modelderived data stored and maintained by the View Cache. It tells thepipeline when derived items change, and gives the pipeline indirectaccess to derived items.

When an LI-1 primitive begins execution, it callsXglViewGrp2dItf::changedComposite() to determine if any of the deriveditems of interest have changed.

    __________________________________________________________________________    //                                                                            // changedComposite determines whether any items of concern have              changed.                                                                      // Upon entry to LI1, a pipeline must call this function before calling       // any other member functions.                                                //                                                                            inline Xg1.sub.-- boolean Xg1ViewGrp2dItf::changedComposite                                       (const Xg1Viewconcern2d* view.sub.-- concern)             TRACE(*Xg1ViewGrp2dItf::changedComposite*);                                   register Xg1.sub.-- usgn32 flag;                                              if (viewCache2d-> curCoordSys != prevCoordSys) {                              flag = viewCache2d-> coordSysChangeFlag                                                         [prevCoordSys][viewCache2d-> curCoordSys];                  nackFlagA |= flag;                                                   prevCoordSys = viewCache2d- > curCoordSys;                                    }                                                                             flag = view.sub.-- concern-> concernFlag[viewCache2d- > curCoordSys];         if (flag & (changeFlagA | nackFlagA)) {                              return TRUE;                                                                  }                                                                             else {                                                                        return FALSE;                                                                 }                                                                             }                                                                             __________________________________________________________________________

This function first checks if the View Cache's current coordinate systemdiffers from the previous coordinate system of the pipeline. If so, thecoordinate system change flag for this transition is combined with the"nack" flag for recording unacknowledged changes caused by changes incoordinate systems. The previous coordinate system of the pipeline isupdated to be the View Cache's current coordinate system.

Then the pipeline's concern flag for the current coordinate systemfilters out the changes to derived items that concern the pipeline.

The changes can either be caused by the application changing the viewmodel attributes or a pipeline changing the current coordinate system.Any changes that pass the filter cause changedComposite() to returntrue, meaning that the pipeline needs to check the individual items forchanges.

4. Detecting Changes to Individual Derived Items

The functions that tell the pipeline if individual derived items havechanged are defined by macros.

    __________________________________________________________________________    // ITF2D.sub.-- CHG.sub.-- DD defines functions for acquiring change          status of derived data.                                                       // FUNC is the name of the function that determines when a change has         occurred.                                                                     // CHG.sub.-- FLAG is the name of the flag that records changes caused by     the                                                                           // application setting attributes.                                            // NACK.sub.-- FLAG is the name of the flag that records changes caused       by a                                                                          // switch in coordinate systems.                                              // DD.sub.-- IDX is the name of the derived data index of the individual      item.                                                                         // DD.sub.-- PTR is the n,me of the pointer to the derived data               evaluation function                                                           // of the individual item.                                                    //                                                                            #define ITF2D.sub.-- CHG.sub.-- DD(FUNC, CHG.sub.-- FLAG, NACK.sub.--         FLAG, DD.sub.-- IDX, DD.sub.-- PTR)                                           inline Xg1.sub.-- boolean Xg1ViewGrp2dItf::FUNC()                             TRACE(*Xg1ViewGrp2dItf::Func*);                                               Xg1.sub.-- usgn32 flag.sub.-- mask;                                           flag.sub.-- mask = viewCache2d->                                                             config[viewCache2d0> curCoordSys].flagTable[DD.sub.--                         IDX];                                                          NACK.sub. -- FLAG &= .sub.-- ˜flag.sub.-- mask;                         if ((CHG.sub.-- FLAG & flag.sub.-- mask) ||                 (DD.sub.-- PTR !=                                                                        viewCache2d-> config(viewCache2d-> curCoordSys].DD.sub.--                     PTR)) {                                                            return TRUE;                                                                  }                                                                             else {                                                                        return FAlSE;                                                                 }                                                                             }                                                                             __________________________________________________________________________

For example, the following macro invocation:

    ______________________________________                                        ITF2D.sub.-- CHG.sub.-- DD(changedMCToCc, changeFlagA, nackFlagA,             XGLI.sub.-- VIEW.sub.-- IDX.sub.-- A.sub.-- MC.sub.-- TO.sub.-- CC,           ptrMCToCc)                                                                    ______________________________________                                    

expands to the following function:

    ______________________________________                                        inline Xg1.sub.-- boolean Xg1ViewGrp2dItf::changedMcToCc()                    TRACE(*Xg1ViewGrp2dItf::Func*);                                               Xg1.sub.-- usgn32 flag.sub.-- mask;                                           flag.sub.-- mask = viewCache2d-> config[viewCache2d->                         curCoordSys].flagTable[XGLI.sub.-- VIEW.sub.-- IDX.sub.-- A.sub.--            MC.sub.-- TO.sub.-- CC];                                                      nackFlagA &= ˜flag.sub.-- mask;                                         if ((changeFlagA & flag.sub.-- mask) ||                     (ptrMcToCc != viewCache2d-> config[viewCache2d->                              curCoordSys].ptrMcToCc)){                                                     return TRUE;                                                                  }                                                                             else {                                                                        return FALSE;                                                                 }                                                                             }                                                                             ______________________________________                                    

In this example, time pipeline calls this function to check for changesto the MC-to-CC Transform. The appropriate Transform depends on thecurrent coordinate system, but the pipeline doesn't need to know thespecific coordinate system. The mapping stored in the View Cache's ViewGroup Configuration for the current coordinate system gives the bit ofthe Transform to be retrieved. This bit is used to clear the nack flag,which indicates only a possibility of a change.

The View Group Interface maintains a set of pointers to evaluationfunctions in the View Cache, just like a View Group Configuration: theyare both derived classes of the View Group class, which defines thesefunction pointers. If the pointer of the View Group Interface differsfrom the corresponding pointer of the View Group Configuration for thecurrent coordinate system, then the pipeline needs to get the item. Thepipeline also needs to get the item if time application changed a viewmodel attribute that invalidated time derived item.

5. Getting a Derived Item

The functions for getting derived items are defined by macros.

    __________________________________________________________________________    // ITF2D.sub.-- GET.sub.-- DD defines functions for getting derived           data.                                                                         // FUNC is the name of the function that gets derived data item.              // FORMAL.sub.-- ARGS is the list of formal arguments of FUNC.                // RET.sub.-- TYPE is the return type of FUNC.                                // CHG.sub.-- FLAG is the name of the flag that records changes caused by     the                                                                           // application setting attributes.                                            // NACK.sub.-- FLAG is the name of the flag that records changes caused       by a                                                                          // switch in coordinate systems.                                              // DD.sub.-- IDX is the name of the derived data index of the individual      item.                                                                         // DD.sub.-- PTR is the name of the pointer to the derived data               evaluation function                                                           // of the individual item.                                                    // ACTUAL.sub.-- ARGS is the list of actual arguments of the evaluation       function                                                                      // pointed to by DD.sub.-- PTR.                                               //                                                                            #define ITF2D.sub.-- GET.sub.-- DD(FUNC, FORMAL.sub.-- ARGS, RET.sub.--       TYPE, CHG.sub.-- FLAG, NACK.sub.-- FLAG,                                      DD.sub.-- IDX, DD.sub.-- PTR, ACTUAL.sub.-- ARGS)                             inline RET.sub.-- TYPE Xg1ViewGrp2dItf::FUNC(FORMAL.sub.-- ARGS)              TRACE(*Xg1ViewGrp2dItf::Func*);                                               Xg1.sub.-- usgn32 flag.sub.-- mask;                                           flag.sub.-- mask = viewCache2d->                                              config[viewCache2d- > curCoordSys].flagTable[DD.sub.-- IDX];                  CHG.sub.-- FLAG &= ˜flag.sub.-- mask;                                   NACK.sub.-- FLAG & = ˜flag.sub.-- mask;                                 }                                                                             DD.sub.-- PTR = viewCache2d-> config[viewCache2d-> curCoordSys].DD.sub.--     PTR;                                                                          return (RET.sub.-- TYPE) ((viewCache2d-> *DD.sub.-- PTR) (ACTUAL.sub.--       ARGS))                                                                        }                                                                             __________________________________________________________________________

For example, the following macro invocation:

    ______________________________________                                        ITF2D.sub.-- GET.sub.-- DD(getMCToCc, , Xg1Transform*,                        changeFlagA, nackFlagA,                                                       XGLI.sub.-- VIEW.sub.-- IDX.sub.-- A.sub.-- MC.sub.-- TO.sub.-- CC,ptrMcTo    Cc,)                                                                          ______________________________________                                    

expands to the following function:

    __________________________________________________________________________    inline Xg1Transform* Xg1ViewGrp2dItf::getMcToCc ( )                           TRACE("Xg1ViewGrp2dItf::Func");                                               Xg1.sub.-- usgn32 flag.sub.-- mask;                                           flag.sub.-- mask = viewCache2d->                                              config[viewCache2d->                                                          curCoordSys].flagTable[XGLI.sub.-- VIEW.sub.-- IDX.sub.-- A.sub.--            MC.sub.-- TO.sub.-- CC];                                                      changeFlagA &= ˜flag.sub.-- mask;                                       nackFlagA &= ˜flag.sub.-- mask;                                         ptrMcToCc = viewCache2d-> config[viewCache2d-> curCoordSys].ptrMcToCc;        return (Xg1Transform*)((viewCache2d-> *ptrMcToCc) ( ));                       }                                                                             __________________________________________________________________________

This function clears both the change and nack flags for the itemretrieved by using the flag from the View Group Configuration for thecurrent coordinate system. It updates the function pointer in the ViewGroup Interface to the one for the retrieved value. Finally, it callsthe evaluation/function in the View Cache by dereferencing the functionpointer.

Summary of Functioning in an Implemented Embodiment

FIG. 6 illustrates process steps taken during a change of attributes byan application program within a given context. This occurs at step 602.Then, upon detection of this occurrence, the interface performs therequested changes to the current view model, however, no calculationsare performed. This update results in derived items in the directedgraph being invalidated by the interface manager at step 604. Then, theviewCache object records this action as a bit field with each bit fieldin the data structure representing a derived item at step 605. Theprocess is thus complete at step 606.

A process which is performed upon the device pipeline calling a graphicsprimitive is illustrated with reference to FIGS. 7a and 7b. Theapplication first calls a graphics primitive, for example, at step 702.Then, the interface manager transfers the view cache's bit field ofinvalidated items to the device pipeline's view group interface to becombined with the bit field of changed items at step 703. In implementedembodiments, geometry is passed to the device pipeline at step 704. Thedevice pipeline then asks view group interface if it's items of concernhave changed, at stop 705. The view group interface then checks it's bitfield of changed items and returns true or false, at step 706. If true,as determined at step 707, the device pipeline asks the view groupinterface if individual items have changed at step 708. For any changeditem, the device pipeline retrieves the item from the view groupinterface at step 709. Then, the process continues at step 710 of FIG.7b.

At step 710, the view group interface retrieves the item(s) from theview cache. The view cache checks the bit field to determine whether theitem has been invalidated. If the item is valid, then the precalculateditem(s) is/are returned at step 713, and the process continues at step715. Otherwise, the acyclic directed graph of dependencies of deriveditems and context attributes, as set forth in FIGS. 5a and 5b, above, isdescended at step 714. At each node in the graph, the object is checkedfor validity. The process stops descending the graph when a valid itemis found. Once a valid item is found, calculated results are moved backup the dependency graph, and each calculation causes the correspondingbit in the validity bit field to be cleared. Once complete, therequested item(s) are valid, and the device pipeline loads valid deriveditem in device at step 715. Then, at step 716, the device pipeline sendsgeometry, including the valid item(s) to the device. The advantages ofthis technique are that the shortcomings of prior art systems areovercome, including, no extraneous calculations of data and noextraneous loading of already valid data.

Thus, using the various data structures and operations discussed above,derived items may be calculated and maintained in a typical computergraphics system in a more efficient manner than the prior art. Also,geometry may be entered from other coordinate systems than thoserequired by certain primitives (e.g. in Model Coordinates), and alsoprovides a fast test to determine if derived items have changed.Although there have been some very specific embodiments described in thepreceding description, these should be viewed as illustrative only, andthe present invention is only to be construed as limited by the appendedclaims which follow.

What is claimed is:
 1. In a computer system which implements a viewmodel including a plurality of coordinate systems, acomputer-implemented method for updating an item within a firstcoordinate system of said plurality of coordinate systems responsive toa change in another coordinate system of said plurality of coordinatesystems, comprising the following steps:a. storing in said computersystem an acyclic graph, said acyclic graph representing dependenciesbetween various items in each of said plurality of coordinate systems;b. upon creation of said item in said first coordinate system of saidplurality of coordinate systems, setting a flag corresponding to saiditem to indicate whether every item of a plurality of items in others ofsaid plurality of coordinate systems is valid in its respectivecoordinate system, wherein said plurality of items are items upon whichsaid item depends; c. setting said flag corresponding to said item toindicate that at least one item of said plurality of items is not validin its respective coordinate system if said change causes any item ofsaid plurality of items to become invalid in its respective coordinatesystem; and d. when an application program references said item,d1.determining whether said flag corresponding to said item indicates thatat least one item of said plurality of items is not valid in itsrespective coordinate system; d2. if said flag corresponding to saiditem indicates that at least one item of said plurality of items is notvalid in its respective coordinate system, theni. descending saidacyclic graph to determine a valid item of said plurality of items, ii.when said valid item is determined, ascending said acyclic graph todetermine each item of said plurality of items which depends on saidvalid item, iii. calculating each item of said plurality of items whichdepends on said valid item, iv. calculating said item, v. setting saidflag corresponding to said item to indicate that each item of saidplurality of items is valid in its respective coordinate system, and vi.presenting said one item to said application program.
 2. The method ofclaim 1 wherein the change causes a given item of said plurality ofitems to become invalid in its respective coordinate system, the methodfurther comprising the step of setting a flag corresponding to each itemthat depends on said given item to indicate that at least one item fromwhich said each item depends is invalid in its respective coordinatesystem.
 3. The method of claim 1 wherein the step of calculating eachitem of said plurality of items which depends on said valid itemincludes calculating said each item after calculating any invalid itemsupon which said each item depends and before calculating any invaliditems which depend on said each item.
 4. The method of claim 1 whereinsaid item is a transform for mapping geometry between two coordinatesystems of said plurality of coordinate systems, the step of calculatingsaid item including the step of calculating said transform.
 5. Themethod of claim 1 wherein said item is an object corresponding to acontext attribute, the step of calculating said item including the stepof calculating said object.
 6. The method of claim 1 wherein said changeis a change to an attribute associated with said other coordinatesystem, the step of setting said flag to indicate that at least one itemof said plurality of items is not valid in its respective coordinatesystem being performed if the item depends on said attribute.
 7. Themethod of claim 1 wherein said change is a change to an object in saidother coordinate system, the step of setting said flag to indicate thatat least one item of said plurality of items is not valid in itsrespective coordinate system being performed if the item depends on saidobject in said other coordinate system.
 8. The method of claim 1 whereinsaid acyclic graph is a linked list, the step of storing said acyclicgraph including storing said linked list.
 9. The method of claim 1wherein said acyclic graph is a series of direct function calls, thestep of storing said acyclic graph including storing code whichimplements said series of direct function calls.
 10. The method of claim1 further including the step of associating said item with an objectwhich includes said flag and a second flag, said second flag indicatingwhether said item is valid in said first coordinate system.
 11. Acomputer system which implements a view model including a plurality ofcoordinate systems, the computer system comprising:item creationcircuitry for creating an item in a first coordinate system of saidplurality of coordinate systems; change circuitry for receiving a changein another coordinate system of said plurality of coordinate systems;structure representation circuitry for storing an acyclic graphrepresenting dependencies between various items in each of saidplurality of coordinate systems; flag setting circuitry, wherein saidflag setting circuitry, upon creation of said item, sets a flagcorresponding to said item to indicate whether each item of a pluralityof items in others of said plurality of coordinate systems is valid inits respective coordinate system, wherein said plurality of items areitems upon which said item depends; said flag setting circuitry settingsaid flag corresponding to said item to indicate that at least one itemof said plurality of items is not valid in its respective coordinatesystem if said change causes any item of said plurality of items tobecome invalid in its respective coordinate system; and referencedetecting circuitry for detecting when an application program referencessaid item; and reference handling circuitry, for handling a reference tosaid item; wherein said reference detecting circuitry activates saidreference handling circuitry when said reference detecting circuitrydetects that said application program referenced said item, wherein saidreference handling circuitry includes:flag checking circuitry fordetermining whether said flag corresponding to said item indicates thatat least one item of said plurality of items is not valid in itsrespective coordinate system; and updating circuitry, said updatingcircuitry updating said item when said flag checking circuitrydetermines that the flag corresponding to said item indicates that atleast one item of said plurality of items is not valid in its respectivecoordinate system, wherein the updating circuitry includes:means fordescending said acyclic graph to determine a valid item of saidplurality of items, means for ascending said acyclic graph to determineeach item of said plurality of items which depends on said valid item,means for calculating each item of said plurality of items which dependson said valid item, means for calculating said item, means for settingsaid flag corresponding to said item to indicate that each item of saidplurality of items is valid in its respective coordinate system, andmeans for presenting said item to said application program.
 12. Thecomputer system of claim 11 wherein the change causes a given item ofsaid plurality of items to become invalid in its respective coordinatesystem, wherein the flag setting circuitry sets a flag corresponding toeach item that depends on said given item to indicate that at least oneitem from which said each item depends is invalid in its respectivecoordinate system.
 13. The computer system of claim 11 wherein the meansfor calculating each item calculates said each item after calculatingany invalid items upon which said each item depends and beforecalculating any invalid items which depend on said each item.
 14. Thecomputer system of claim 11 wherein said item is a transform for mappinggeometry between two coordinate systems of said plurality of coordinatesystems.
 15. The computer system of claim 11 wherein said item is anobject corresponding to a context attribute.
 16. The computer system ofclaim 11 wherein said change is a change to an object in said othercoordinate system.
 17. The computer system of claim 11 wherein saidacyclic graph is a linked list.
 18. The computer system of claim 11wherein said acyclic graph is a series of direct function calls.
 19. Thecomputer system of claim 11 further including means for associating saiditem with an object which includes said flag and a second flag, saidsecond flag indicating whether said item is valid in said firstcoordinate system.
 20. In a computer system having a plurality ofcoordinate systems including a current coordinate system, a method fordeterminating whether any derived item of a plurality of derived itemsassociated with a device pipeline is invalid, comprising the stepsof:causing said device pipeline to specify said plurality of deriveditems; providing a first flag word associated with said device pipeline,said first flag word having a first plurality of bits, each bit of saidfirst plurality of bits corresponding to a derived item of saidplurality of derived items; providing a second flag word associated withsaid device pipeline, said second flag word having a second plurality ofbits, each bit of said second plurality of bits corresponding to aderived item of said plurality of derived items; setting a first bitcorresponding to a given derived item when an application sets a viewmodel attribute, said first bit being a bit in said first plurality ofbits; setting a second bit corresponding to the given derived item whenan unacknowledged change occurs in the current coordinate system, saidsecond bit being a bit in said second plurality of bits; and determiningwhether any derived item of said plurality of derived items is invalidbased on said first flag word and said second flag word.